[% setvar title docs/pdds/pdd01_overview.pod - A high-level overview of the Parrot system %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='NAME'></a><h1>NAME</h1>
<p>docs/pdds/pdd01_overview.pod - A high-level overview of the Parrot system</p>
<a name='ABSTRACT'></a><h1>ABSTRACT</h1>
<p>This PDD provides a high-level overview of the Parrot system.</p>
<a name='DESCRIPTION'></a><h1>DESCRIPTION</h1>
<a name='Major components'></a><h2>Major components</h2>
<p>The Parrot system generally looks like this:</p>
<pre> +----------------------------------------------------+
 |                   Embedding App                    |
 +----------+------------+-------------+--------------+
 |          |            |             |              |
 |  parser &lt;-&gt; compiler &lt;-&gt; optimizer &lt;-&gt; interpreter |
 |          |            |             |              |
 +----------+------------+-------------+--------------+
 |                Extensions to Parrot                |
 +----------------------------------------------------+ </pre>
<ul>
<li><a name='Parser'></a>Parser</li>
<p>The parser takes source code of some sort and creates a syntax tree of
that source.</p>
<p>Different high level languages will generally have their own parser
modules, implemented in whatever language is most convenient. For instance,
we currently intend to write the parser for Perl 6 in Perl 6, to allow
for easy extension. Generally there will be one parser per language, though
there's no reason that there can't be multiple independent parsers.</p>
<li><a name='Bytecode compiler'></a>Bytecode compiler</li>
<p>The bytecode compiler module takes a syntax tree from the parser and
emits an unoptimized stream of bytecode. This code is suitable for
passing straight to the interpreter, though it is probably not going
to be very fast.</p>
<li><a name='Optimizer'></a>Optimizer</li>
<p>The optimizer module takes the bytecode stream from the compiler and
optionally the syntax tree the bytecode was generated from, and
optimizes the bytecode.</p>
<li><a name='Interpreter'></a>Interpreter</li>
<p>The interpreter module takes the bytecode stream from either the
optimizer or the bytecode compiler and executes it. There must always
be at least one interpreter module available for any program that can
handle all of Perl, since it's required for use statements and BEGIN
blocks.</p>
<p>While there must be at least one interpreter, there may be multiple
interpreter modules linked into an executable. This would be the case,
for example, for programs that produced Java bytecode, where one of
the interpreter modules would take the bytecode stream and spit out
Java bytecode instead of interpreting it.</p>
</ul>
<a name='Independent subsystems'></a><h2>Independent subsystems</h2>
<p>Parrot also has a number of subsystems that are independent of any
single module.</p>
<ul>
<li><a name='ParrotIO subsystem'></a>ParrotIO subsystem</li>
<p>The ParrotIO subsystem provides source- and platform-independent
asynchronous I/O to Parrot. The intent is to make Parrot (and any
languages that run on it) independent of C's stdio system. (And good
riddance--it sucks) How this maps to the OS's underlying I/O code is not
generally Parrot's concern, and a platform isn't obligated to provide
asynchronous I/O.</p>
<p>Additionally, the ParrotIO subsystem allows a program to push filters
onto an input stream if necessary, to manipulate the data before it is
presented to a program.</p>
<li><a name='Regex engine'></a>Regex engine</li>
<p>By providing a regular expression engine as a separate subsystem of
Parrot, we intend to make it easily available to any language running
on Parrot (cf. the Perl 5 regex engine, which is intimately linked to
the perl core). The job of the regex engine is to turn regexes into objects,
and apply those regex objects to strings.</p>
</ul>
<a name='API levels'></a><h2>API levels</h2>
<ul>
<li><a name='Embedding'></a>Embedding</li>
<p>The embedding API is the set of calls exported to the embedding
application. This is a small, simple set of calls, requiring minimum
effort to use.</p>
<p>The goal is to provide an interface that a competent programmer who is
uninterested in Parrot internals can use to provide access to a Parrot
interpreter within another application with very little programming or
intellectual effort. Generally it should take less than thirty minutes
for a simple interface, though more complete integration will take
longer.</p>
<p>Backwards binary compatibility at this level is guaranteed across the
life of Parrot.</p>
<li><a name='Extensions'></a>Extensions</li>
<p>The extension API is the set of calls exported to Parrot
extensions. They provide access to most of the things an extension
needs to do, while hiding the implementation details. (So that, for
example, we can change the way scalars are stored without having to
rewrite, or even recompile, an extension).</p>
<p>Binary compatibility is a serious goal, though it may be broken if
absolutely necessary.</p>
<li><a name='Guts'></a>Guts</li>
<p>The guts-level APIs are the routines used within a component. These
aren't guaranteed to be stable, and shouldn't be used outside a
component. (For example, an extension to the interpreter shouldn't
call any of the parser's internal routines).</p>
<p>No binary compatibility is guaranteed, and routines here may be
changed without notice.</p>
</ul>
<a name='VARIATIONS ON A THEME'></a><h1>VARIATIONS ON A THEME</h1>
<p>One of the explicit goals of the Parrot project is to generate Java
bytecode and .NET code, as well as to run on small devices such as the Palm.
The modular nature of the Parrot system makes this reasonably straightforward.</p>
<ul>
<li><a name='Parrot for small platforms'></a>Parrot for small platforms</li>
<p>For small platforms, any parser, compiler, and optimizer modules are
replaced with a small bytecode loader module which reads in Parrot
bytecode and passes it to the interpreter for execution. Note that
the lack of a parser will limit the available functionality in some
languages: for instance, in Perl, string eval, do, use, and require
will not be available (although loading of precompiled modules via do,
use, or require may be supported).</p>
<li><a name='Bytecode compilation'></a>Bytecode compilation</li>
<p>One straightforward use of the Parrot system is to precompile a
program into bytecode and save it for later use. Essentially, we
would compile a program as normal, but then simply freeze the
bytecode to disk for later loading.</p>
<li><a name='Perl in, Java (or whatever) out'></a>Perl in, Java (or whatever) out</li>
<p>The previous section implicitly assumes that we will be emitting
Parrot bytecode. However, there are other possibilities: we could
translate the bytecode to Java bytecode or .NET code, or even to a
native executable. In principle, Parrot could also act as a front end to
other modular compilers such as gcc or HP's GEM compiler system.</p>
<li><a name='Standalone pieces'></a>Standalone pieces</li>
<p>Each piece of Parrot can, with enough support hidden away (in the form
of an interpreter for the parsing module, for example), stand on its
own. This means it's feasible to make the parser, bytecode compiler,
optimizer and interpreter separate executables.</p>
<p>This allows us to develop pieces independently--the first version of
the Perl 6 parser, for example, can be written mainly in perl 5 using an
embedded interpreter. It also means we can have a standalone optimizer
which can spend a lot of time groveling over bytecode, far more than
you might want to devote to optimizing one-liners or code that'll run
only once or twice.</p>
</ul>
<a name='VERSION'></a><h1>VERSION</h1>
<a name='CURRENT'></a><h2>CURRENT</h2>
<pre>    Maintainer: Dan Sugalski
    Class: Meta
    PDD Number: 1
    Version: 1
    Status: Developing
    Last Modified: 12 August 2003
    PDD Format: 1
    Language: English</pre>
<a name='HISTORY'></a><h2>HISTORY</h2>
<ul>
<li><a name='1.1'></a>1.1</li>
<p>12 Aug 2003</p>
<li><a name='1.0'></a>1.0</li>
<p>02 Jan 2001</p>
</ul>
<a name='CHANGES'></a><h1>CHANGES</h1>
<ul>
<li><a name='1.1'></a>1.1</li>
<p>Changed perl to Parrot where appropriate. Rewrote some sections to
reflect the language agnostic nature of the project.</p>
<li><a name='1.0'></a>1.0</li>
<p>None. First version</p>
</ul>
</div>
